A pattern for building personal knowledge bases using LLMs. Extended with lessons from building agentmemory 20K+ Stars ⭐️, a persistent memory engine for AI coding agents.

This builds on Andrej Karpathy's original LLM Wiki idea file. Everything in the original still applies. This document adds what we learned running the pattern in production: what breaks at scale, what's missing, and what separates a wiki that stays useful from one that rots.

The core insight is correct: stop re-deriving, start compiling. RAG retrieves and forgets. A wiki accumulates and compounds. The three-layer architecture (raw sources, wiki, schema) works. The operations (ingest, query, lint) cover the basics. If you haven't read the original, start there.

日本語で技術的な原稿（書籍の章、記事、解説文）を書く・推敲するときは、以下の規範に従う。

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

Optimize the Rust and Python bindings in this Rust crate to its maximum potential. Specifically, you MUST make a breakthrough from this current implementation that uses modern concepts and knowledge as of 2026 to further improve this crate without causing ANY significant regressions.

First, before making any library changes, run the Rust and Python benchmarks (and any competitor benchmarks if applicable) to establish a True Performance Baseline for both speed and metric performance. Return the absolute and relative results to the True Performance Baseline to the user as a Markdown table.

Then, optimize the Rust and Python library code such that these benchmarks are atleast 1.2x faster from the True Performance Baseline; ideally as fast as possible, without any significant regressions on quality and prediction error. NEVER hack the benchmarks to accomplish this speed increase, only iterate on the library code. Ensure all benchmark iterations are independent, e.g. NEVER reuse a cache built in

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

• elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

This document provides guidelines for maintaining high-quality Rust code. These rules MUST be followed by all AI coding agents and contributors.

All code you write MUST be fully optimized.

"Fully optimized" includes: